1. Technical Field
The invention relates to security trusts. More particularly, the invention relates to allowing code signed by a master key to grant trust to an arbitrary second key, and allowing code, referred to as an antidote, also signed by the master key to revoke permanently the trust given to the secondary key.
2. Description of the Prior Art
Simply speaking, computer systems are at a state such that companies can relatively easily distribute a lot of code to a lot of end users. To protect their code or their product from hackers and unknown impurities, such companies typically apply a security mechanism. An example of a security mechanism is trust using Certificate Revocation Lists (CRL).
In this context, the definition of trust has two parts. The first part is establishing identity of a participant. Typically, the participant has, as an analogy a letter of introduction signed by some other entity. The signing entity is typically referred to as a certificate of authority, or CA. The certificate of authority, or simply, certificate establishes the participant's name and signature. Other terms used interchangeably with certificate are master key, super key, and system certificate. Therefore, the participant's identity is a letter of introduction signed by a CA.
The second part is a statement of trust, which according to the analogy above may be a letter stating trust the participant. That is, the first step is to establish identity of a participant, and the second step is an agreement provided stating trust such identity. The identity and the agreement together work to establish trust.
From a typical computer system's perspective, an example of an implementation of trust is accomplished by using CRL's. The use of CRL's is bundled with the released software. Associated with the released software is a system certificate. This certificate along with a plurality of other certificates reside in a certificate database. The use of certificates is adaptable to be applied to releases of additional software released by the same entity that released the first system code. Sometimes they are referred to as patches. Signed patches mean for the end user to trust the patches as well as the originally signed software.
Another level of complexity is added by desiring partner or vendor code to be released with the original system code. In order for all three types of code, original system code, patches, and partner code to work together seamlessly, they all currently need to be signed by the same certificate.
Currently, in the event that the partner code is faulty and was signed by the certificate, then the system code and its patches are at jeopardy. The current remedy is to modify the partner code for corrections and re-release it. However, because the erroneous partner code was signed by the certificate, the certificate's power must be revoked. Revoking the certificate's power impacts trust granted to the signed original system code and any of its signed patches. A second master key or certificate needs to be created to sign the original system code, its patches, and the corrected partner code prior to their re-release.
Obviously, re-releasing good software (original system and patches) is a redundant process that can prove crippling and prohibitively expensive for a company.
It is also a major task for a company to re-release corrected partner software when the partner software is of a large quantity, which is typically the case.
It could also be very detrimental to a company should its partner provide code unbeknownst to the company or to the partner until after its release contain code that is offensive and cannot be revoked in a timely and efficient manner.
R. Sudama, D. M. Griffin, B. Johnson, D. Sealy, J. Shelhamer, and O. H. Tallman, U.S. Pat. No. 5,619,657 (Apr. 8, 1997) discloses a method for providing a security facility for a network of management servers utilizing a database of trust relations to verify mutual trust relations between management servers. The disclosure consists of a method for providing security for distributing management operations among components of a computer network using a network of mutually trusting, mutually authenticating management services to dispatch operations to selected host systems. Mutual authentication and trust are established on every transmission link from a point of submission to a designated management server which invokes a service provider to perform management operations on a selected host.
However, Sudama of al. requires the prior art standard technique of querying a database to the trusted identification of concern and does not comprise revoking trust.
M. Gasser, A. C. Goldstein, C. W. Kaufman, and B. W. Lampson, U.S. Pat. No. 5,224,163 (Jun. 29, 1993) discloses a method for delegating authorization from one entity in a distributed computing system to another in a single computing session through the use of a session public/private encryption key pair. At the end of the computing session, the private encryption key is erased and terminates the computing session.
Gasser et al. addresses security on a temporary, or session basis. In addition, the user is required to certify that the workstation in question possessing the private encryption key is authorized to speak on the user's behalf.
It would be advantageous to provide an elegant, simple, and efficient means to revoke the trust previously granted to partner code.
It would be advantageous to allow partner code to be signed by its own, unique certificate so as not to impact the release of other code signed by other certificates.
It would be advantageous to revoke a minor key for destroying trust of partner code and reassign a new minor key to grant trust to corrected or modified partner code, rather than re-releasing or shipping all code signed by a master key.